home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 745 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  5.0 KB
  1. Subject: Re: Gem List (fwd)
  2. Date: Mon, 11 Jul 1994 13:22:16 -0400 (EDT)
  3. From: Chris Herborth <herborth@53iss6.waterloo.NCR.COM>
  4. In-Reply-To: <199407111621.AA08672@world.std.com> from "Lexicor@world.std.com" at Jul 11, 94 12:21:08 pm
  5. Message-Id:  <9407111325.af16466@ncrhub1.NCR.COM>
  6. Precedence: bulk
  7.  
  8. What you wrote:
  9. > Warwick, are you SURE you understand what Extended Object Types are?  From
  10. > the way you speak, it sounds like you have no idea why they were designed.
  11.  
  12. >From the sound of the following flame-bait, you have no idea how object-
  13. oriented programming works.
  14.  
  15. > You're saying that with Gem++ you would have to add code to support the
  16. > active slider, perhaps doing something like "register_active_slider(TREE,
  17. > object, orientation);" which is insane. Having to write code to support
  18. > an interface when the interface should do those things ITSELF is a pain.
  19.  
  20. Nothing is a pain with GEM++...  ;-)
  21.  
  22. OOP is mainly customizing objects for your own use, once the library is
  23. finished, that is.  Warwick built GEM++ from scratch, so he did all the
  24. hard work.  Now if _I_ use GEM++ for a dialog-in-a-window or something,
  25. it takes about 5 lines of code.  I don't have to do anything special to
  26. the dialog in the RSC editor, and the code I _do_ write for my dialog
  27. is exactly what I'd have to write for a normal dialog... something to
  28. figure out what switches were set, what exit button was pushed, etc.
  29.  
  30. > Besides the fact that if you want to change the functionality of a button,
  31. > you can't do it visually, you have to do it programatically. This is right
  32. > along the lines of insanity that MultiTOS did when they forced you to do
  33. > heirarchical menus by linking them together within your code, rather than
  34. > the *obvious* way of allowing you to design heirarchical menus using
  35. > a resource editor.
  36.  
  37. That's a "feature" of not having an up-to-date RSC editor that can build
  38. RSC objects for the new AES.  If they'd built one of those, adding the
  39. hierarchical menus in a saner way would've been easy.
  40.  
  41. > If you want to make a quick change to your interface, with Gem++ you would
  42. > have to recompile the code. With all other libraries it's just a quick dip
  43. > into a resource editor to make that change.
  44.  
  45. And possibly a complete re-build of your entire application so you can
  46. use the new extended-GEM library headers and link it with the new library.
  47. If you _started_ with that library, it might just be a flick of a bit in
  48. your RSC editor, which is also prone to errors... all the RSC editors I've
  49. seen that let you modify the extended-object bits list the bits, since
  50. they can't say what they're used for... hackery at its best.
  51.  
  52. > To me, this seems like an *ENORMOUS* disadvantage of Gem++, as it is with
  53. > MultiTOS. A library is supposed to make coding easier, not more difficult.
  54.  
  55. I guess you've never compared the GUI code for an *application* using GEM++
  56. to that built with a "normal" library...  Accessing strings in a RSC
  57. (anywhere... free strings, strings in dialogs, strings in menus, etc) is
  58. incredibly easy, for example, which makes it feasable to put *all* program
  59. text into the RSC instead of hard-coding it.  The feature makes it a no-
  60. brainer to translate your program into another language, something that's
  61. almost a necessity in today's Atari market, just to get a reasonable
  62. number of potential users.
  63.  
  64. > Is it any wonder why nobody has used Gem++ for anything yet? :-)
  65.  
  66. Speak for yourself.  Most people don't use GEM++ for anything because:
  67.  
  68. 1) They're afraid of GNU C/C++, since it's not a commercial product.
  69. 2) There's no commercial C++ implementation for the Atari.
  70. 3) They don't know OOP or C++.
  71. 4) They think learning to use a poorly documented C library would be
  72.    easier than learning to use C++, OOP, and a (currently) poorly
  73.    documented C++ library.  GEM++'s documentation will be vastly
  74.    improved for the next release, since I keep bugging Warwick and
  75.    proofing his docs.  I also do some work on a GEM++ tutorial now
  76.    and then.
  77. 5) Their ST is too damn slow for C++ development.
  78. 6) Their ST doesn't have enough RAM for C++ development (it gets _really_
  79.    tight in 4M of RAM).
  80. 7) Their ST doesn't have a hard drive (!), which is pretty necessary
  81.    for GNU C/C++, since the compiler is over a meg in size.
  82. 8) Inertia.
  83.  
  84. 8 is the scariest, IMHO, since you can get around 1+2 by being convinced
  85. that GNU C builds the best Atari code (it beats *all* of the commercial
  86. compilers), 3+4 just require a bit of reading, and 5+6+7 are easily
  87. cured by upgrading (hahaha... yeah.) or getting a cross-compiler
  88. going.
  89.  
  90. Inertia as a reason for resisting OOP is a very bad thing; it's going to
  91. become VERY important in the next several years, whether as Smalltalk,
  92. C++, Objective-C, Python, or whatever.  It's the only sensible choice
  93. for large software projects, and they certainly are getting larger...
  94.  
  95. -- 
  96. ----------========================_   /\ ============================----------
  97. Chris Herborth                    \`o.0'       herborth@53iss6.Waterloo.NCR.COM
  98. Information Products Developer    =(___)=
  99. AT&T Global Information Solutions    U
  100.